home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 3.4 KB | 88 lines | [TEXT/GEOL] |
- Item 7820398 25-Aug-89 14:29
-
- From: D2512 Decision Sys, Andrew C Esh,PRT
-
- To: MACDTS Macintosh Developer Tech. Supt.,APL
-
- cc: MACAPP.TECH$ MACAPP Tech
-
- Sub: MacApp 2.0ß9 BUG
-
- (Please pass this to your MacApp 2.0ß9 people)
-
- Dear Fellow OOP-Heads:
- I have two problems which I had to patch MacApp 2.0ß9 to fix:
-
- The following is a copy of my version of TCtlMgr.Free, which fixes a
- problem that MacApp 2.0ß9 has. I noticed this when removing a TDialogView,
- which contains a TCheckBox, from a more complex view. An area the size of the
- CheckBox, located the same offset from the upper left corner of the SCREE
- the real CheckBox is located within the WINDOW, is erased. There is obviously
- a Local-To-Global missing here. I would also rather that there is no erasure,
- even if it is on target.
- After some tracing with TMON I discovered that SizeControl is called to set
- the control size to zero, so no erasure takes place when the control is
- disposed. SizeControl is calling HideControl to clear the area that the
- control may be uncovering, if it is being made smaller. Fair enough. Not what
- TCtlMgr.Free needs, though ...
-
- PROCEDURE TCtlMgr.Free; OVERRIDE;
-
- BEGIN
-
- IF fCMgrControl <> NIL THEN
- BEGIN
-
- (* &A& Changed to keep SizeControl from erasing the control.
- (SizeControl calls HideControl at $811EC4 in Mac II ROM)
- Also, fCMgrControl is at local coordinates, not the global
- coordinates that SizeControl assumes, so the erasure takes
- place at the wrong location on the screen.
-
- SizeControl(fCMgrControl, 0, 0);{ Prevent CMgr from erasing the control! }
- *)
- SetRect(fCMgrControl^^.contrlRect,
- fCMgrControl^^.contrlRect.left, fCMgrControl^^.contrlRect.top,
- fCMgrControl^^.contrlRect.left, fCMgrControl^^.contrlRect.top);
- DisposeControl(fCMgrControl);
-
- END;
-
- INHERITED Free;
- END;
-
-
- I realize the way I did this probably really sucks, but it works for me, so
- I don't care.
-
- The other complaint I have is that the TGridView.IRes method inserts the
- rows before the columns. This is Antilexicographical (great word!) and forces
- any companion storage schemes to be the same. In my code, I overrode the row
- insertion routine and added code to also expand my text storage area by a row
- at a time, but was unable to insert the initial rows, since fNumOfCols doesn't
- get initialized until after InsertRowFirst gets called in the TGridView.IRes
- method. Since it is more likely that whole rows will be added than whole
- columns, lets get fNumOfCols defined first, so the rows can be added at full
- width.
- I fixed this by switching the order that InsertColFirst and InsertRowFirst
- get called: (from IRes code)
-
- { &A& Had to reverse these so fNumOfCols would be set before InsRowFirst }
-
- IF (numOfCols > 0) THEN
- InsColFirst(numOfCols, colWidth);
- IF (numOfRows > 0) THEN
- InsRowFirst(numOfRows, rowHeight);
-
- This fixed my problem, and now my text storage scheme and your GridView
- initialization routine agree.
-
- By the way, when will 2.0 be finalized?
-
- - Andrew
-
- P.S. I just noticed another bug. The editor for AppleLink 4.0 does not scroll
- the window to keep the cursor visible if the cursor goes off the top edge of
- the screen. Must be something in the air today, I'm finding everything.
-
-